home *** CD-ROM | disk | FTP | other *** search
-
-
-
-
-
-
- Network Working Group K. McCloghrie, Editor
- Request for Comments: 1229 Hughes LAN Systems, Inc.
- May 1991
-
-
- Extensions to the Generic-Interface MIB
-
- Status of this Memo
-
- This RFC contains definitions of managed objects used as experimental
- extensions to the generic interfaces structure of MIB-II. This memo
- is a product of the SNMP Working Group of the Internet Engineering
- Task Force (IETF). This RFC specifies an IAB standards track
- protocol for the Internet community, and requests discussion and
- suggestions for improvements. Please refer to the current edition of
- the "IAB Official Protocol Standards" for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
- Table of Contents
-
- 1. Abstract .............................................. 1
- 2. The Network Management Framework....................... 1
- 3. Objects ............................................... 2
- 4. Overview .............................................. 3
- 4.1 Generic Interface Extension Table .................... 3
- 4.2 Generic Interface Test Table ......................... 3
- 4.3 Generic Receive Address Table ........................ 4
- 5. Definitions ........................................... 5
- 6. Acknowledgements ...................................... 14
- 7. References ............................................ 15
- 8. Security Considerations................................ 15
- 9. Author's Address....................................... 16
-
- 1. Abstract
-
- This memo defines an experimental portion of the Management
- Information Base (MIB) for use with network management protocols in
- TCP/IP-based internets. In particular, it defines managed object
- types as experimental extensions to the generic interfaces structure
- of MIB-II.
-
- 2. The Network Management Framework
-
- The Internet-standard Network Management Framework consists of three
- components. They are:
-
- RFC 1155 which defines the SMI, the mechanisms used for describing
- and naming objects for the purpose of management. RFC 1212
-
-
-
- SNMP Working Group [Page 1]
-
- RFC 1229 Interface MIB Extensions May 1991
-
-
- defines a more concise description mechanism, which is wholly
- consistent with the SMI.
-
- RFC 1156 which defines MIB-I, the core set of managed objects for
- the Internet suite of protocols. RFC 1213, defines MIB-II, an
- evolution of MIB-I based on implementation experience and new
- operational requirements.
-
- RFC 1157 which defines the SNMP, the protocol used for network
- access to managed objects.
-
- The Framework permits new objects to be defined for the purpose of
- experimentation and evaluation.
-
- 3. Objects
-
- Managed objects are accessed via a virtual information store, termed
- the Management Information Base or MIB. Objects in the MIB are
- defined using the subset of Abstract Syntax Notation One (ASN.1) [7]
- defined in the SMI. In particular, each object has a name, a syntax,
- and an encoding. The name is an object identifier, an
- administratively assigned name, which specifies an object type. The
- object type together with an object instance serves to uniquely
- identify a specific instantiation of the object. For human
- convenience, we often use a textual string, termed the OBJECT
- DESCRIPTOR, to also refer to the object type.
-
- The syntax of an object type defines the abstract data structure
- corresponding to that object type. The ASN.1 language is used for
- this purpose. However, the SMI [3] purposely restricts the ASN.1
- constructs which may be used. These restrictions are explicitly made
- for simplicity.
-
- The encoding of an object type is simply how that object type is
- represented using the object type's syntax. Implicitly tied to the
- notion of an object type's syntax and encoding is how the object type
- is represented when being transmitted on the network.
-
- The SMI specifies the use of the basic encoding rules of ASN.1 [8],
- subject to the additional requirements imposed by the SNMP.
-
- Section 5 contains the specification of all object types in this
- section of the MIB. The object types are defined using the
- conventions specified in the SMI, as amended by the extensions
- specified in [9].
-
-
-
-
-
-
- SNMP Working Group [Page 2]
-
- RFC 1229 Interface MIB Extensions May 1991
-
-
- 4. Overview
-
- The Internet Standard MIB [4,6] contains a group of management
- objects pertaining to a network device's generic network
- interface(s). These objects are generic in the sense that they apply
- to all network interfaces, irrespective of the type of communication
- media and protocols used on such interfaces. This has proved to be
- necessary but not sufficient; there are efforts underway to define
- additional MIB objects which are specific to particular media and
- lower-level (subnetwork-layer and below) protocol stacks.
-
- However, some of these efforts have identified objects which are
- required (or at least useful), but are not specific to the
- interface-type on which the effort is focusing. In order to avoid
- redundancy, it is better that such objects be defined as extensions
- to the generic interface group, rather than defined in multiple
- specific-interface-type MIBs.
-
- This memo defines the resultant extensions to the generic interface
- group. These extensions are spread over three tables: the generic
- Interface Extension table, the generic Interface Test table, and the
- generic Receive Address table.
-
- 4.1. Generic Interface Extension Table
-
- This table consists of new objects applicable to all types of
- subnetwork interface.
-
- 4.2. Generic Interface Test Table
-
- This section defines objects which allow a network manager to
- instruct an agent to test an interface for various faults. A few
- common types of tests are defined in this document but most will be
- defined elsewhere, dependent on the particular type of interface.
- After testing, the object ifExtnsTestResult can be read to determine
- the outcome. If an agent cannot perform the test, ifExtnsTestResult
- is set to so indicate. The object ifExtnsTestCode can be used to
- provide further test-specific or interface-specific (or even
- enterprise-specific) information concerning the outcome of the test.
- Only one test can be in progress on each interface at any one time.
- If one test is in progress when another test is invoked, the second
- test is rejected. Some agents may reject a test when a prior test is
- active on another interface.
-
- When a test is invoked, the identity of the originator of the request
- and the request-id are saved by the agent in the objects
- ifExtnsTestRequestId and ifExtnsTestCommunity. These values remain
- set until the next test is invoked. In the (rare) event that the
-
-
-
- SNMP Working Group [Page 3]
-
- RFC 1229 Interface MIB Extensions May 1991
-
-
- invocation of tests by two network managers were to overlap, then
- there would be a possibility that the first test's results might be
- overwritten by the second test's results prior to the first results
- being read. This unlikely circumstance can be detected by a network
- manager retrieving ifExtnsTestCommunity, and ifExtnsTestRequestId at
- the same time as the test results are retrieved, and ensuring that
- the results are for the desired request.
-
- In general, a Management station must not retransmit a request to
- invoke a test for which it does not receive a response; instead, it
- properly inspects an agent's MIB to determine if the invocation was
- successful. The invocation request is retransmitted only if the
- invocation was unsuccessful.
-
- Some tests may require the interface to be taken off-line or may even
- require the agent to be rebooted after completion of the test. In
- these circumstances, communication with the management station
- invoking the test may be lost until after completion of the test.
- The agent should make every effort to transmit a response to the
- request that invoked the test prior to losing communication. When
- the agent is restored to normal service, the results of the test are
- properly made available in the appropriate objects. Note that this
- requires that the ifIndex value assigned to an interface must be
- unchanged even if the test causes a reboot. An agent must reject any
- test for which it cannot, perhaps due to resource constraints, make
- available at least the minimum amount of information after that test
- completes.
-
- 4.3. Generic Receive Address Table
-
- This table contains objects relating to an interface's support for
- receiving packets/frames at more than one address on the same
- interface.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- SNMP Working Group [Page 4]
-
- RFC 1229 Interface MIB Extensions May 1991
-
-
- 5. Definitions
-
-
- RFC1229-MIB DEFINITIONS ::= BEGIN
-
-
- -- Extensions to MIB-II's Generic Interface Table
-
- IMPORTS
- experimental, Counter FROM RFC1155-SMI
- DisplayString, PhysAddress FROM RFC1213-MIB
- OBJECT-TYPE FROM RFC-1212;
-
-
-
- ifExtensions OBJECT IDENTIFIER ::= { experimental 6 }
-
-
- -- Generic Interface Extension Table
- --
- -- This group of objects is mandatory for all types of
- -- subnetwork interface.
-
- ifExtnsTable OBJECT-TYPE
- SYNTAX SEQUENCE OF IfExtnsEntry
- ACCESS not-accessible
- STATUS mandatory
- DESCRIPTION
- "A list of interfaces extension entries.
- The number of entries is given by the value
- of ifNumber, defined in [4,6]."
- ::= { ifExtensions 1 }
-
- ifExtnsEntry OBJECT-TYPE
- SYNTAX IfExtnsEntry
- ACCESS not-accessible
- STATUS mandatory
- DESCRIPTION
- "An extension to the interfaces entry,
- defined in [4,6], containing additional
- objects at the subnetwork layer and below
- for a particular interface."
- INDEX { ifExtnsIfIndex }
- ::= { ifExtnsTable 1 }
-
- IfExtnsEntry ::=
- SEQUENCE {
- ifExtnsIfIndex
-
-
-
- SNMP Working Group [Page 5]
-
- RFC 1229 Interface MIB Extensions May 1991
-
-
- INTEGER,
- ifExtnsChipSet
- OBJECT IDENTIFIER,
- ifExtnsRevWare
- DisplayString,
- ifExtnsMulticastsTransmittedOks
- Counter,
- ifExtnsBroadcastsTransmittedOks
- Counter,
- ifExtnsMulticastsReceivedOks
- Counter,
- ifExtnsBroadcastsReceivedOks
- Counter,
- ifExtnsPromiscuous
- INTEGER
- }
-
- ifExtnsIfIndex OBJECT-TYPE
- SYNTAX INTEGER
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "The value of this object identifies the
- interface for which this entry contains
- extended management information. The value
- of this object for a particular interface
- has the same value as the ifIndex object,
- defined in [4,6], for the same interface."
- ::= { ifExtnsEntry 1 }
-
- ifExtnsChipSet OBJECT-TYPE
- SYNTAX OBJECT IDENTIFIER
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "This object identifies the hardware chip
- set being used in the interface. The
- assignment of OBJECT IDENTIFIERs to various
- types of hardware chip sets is managed
- by the IANA. If the hardware chip set is
- unknown, the object identifier
-
- unknownChipSet OBJECT IDENTIFIER ::= { 0 0 }
-
- is returned. Note that unknownChipSet is a
- syntactically valid object identifier, and
- any conformant implementation of ASN.1 and
- the BER must be able to generate and
-
-
-
- SNMP Working Group [Page 6]
-
- RFC 1229 Interface MIB Extensions May 1991
-
-
- recognize this value."
- ::= { ifExtnsEntry 2 }
-
- ifExtnsRevWare OBJECT-TYPE
- SYNTAX DisplayString (SIZE (0..255))
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "An arbitrary octet string that describes
- the firmware version of this interface.
- It is intended that this should be human
- readable. It must only contain ASCII
- printable characters. Typically this
- will be the firmware version of the main
- interface software."
- ::= { ifExtnsEntry 3 }
-
- ifExtnsMulticastsTransmittedOks OBJECT-TYPE
- SYNTAX Counter
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "The count of frames successfully
- transmitted to a subnetwork or link-layer
- multicast destination address other than a
- broadcast address. For a MAC layer protocol,
- this includes both Group and Functional
- addresses."
- ::= { ifExtnsEntry 4 }
-
- ifExtnsBroadcastsTransmittedOks OBJECT-TYPE
- SYNTAX Counter
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "The count of frames successfully
- transmitted to a subnetwork or link-layer
- broadcast addresses. It does not include
- frames sent to a multicast address."
- ::= { ifExtnsEntry 5 }
-
- ifExtnsMulticastsReceivedOks OBJECT-TYPE
- SYNTAX Counter
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "The count of frames successfully received
- that are directed to an active subnetwork
-
-
-
- SNMP Working Group [Page 7]
-
- RFC 1229 Interface MIB Extensions May 1991
-
-
- or link-layer multicast address (for a MAC
- layer protocol, this includes both Group and
- Functional addresses). This does not include
- frames directed to a broadcast address, nor
- frames received with errors."
- ::= { ifExtnsEntry 6 }
-
- ifExtnsBroadcastsReceivedOks OBJECT-TYPE
- SYNTAX Counter
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "The count of frames successfully received
- that are directed to a subnetwork or
- link-layer broadcast address. This does not
- include frames received with errors."
- ::= { ifExtnsEntry 7 }
-
- ifExtnsPromiscuous OBJECT-TYPE
- SYNTAX INTEGER {
- true(1),
- false(2)
- }
- ACCESS read-only -- Note: agent implementors are
- -- encouraged to extend this
- -- access to read-write if that
- -- makes sense in their agent.
- STATUS mandatory
- DESCRIPTION
- "This object has a value of false(2) if
- this interface only accepts packets/frames
- that are addressed to this station. This
- object has a value of true(1) when the
- station accepts all packets/frames
- transmitted on the media. The value
- true(1) is only legal on certain types of
- media. If legal, setting this object to a
- value of true(1) may require the interface
- to be reset before becoming effective."
- ::= { ifExtnsEntry 8 }
-
- --
- -- Generic Interface Test Table
- --
- -- This group of objects is optional, but if the table is
- -- implemented, all objects in the table must be implemented.
-
-
-
-
-
- SNMP Working Group [Page 8]
-
- RFC 1229 Interface MIB Extensions May 1991
-
-
- ifExtnsTestTable OBJECT-TYPE
-
- SYNTAX SEQUENCE OF IfExtnsTestEntry
- ACCESS not-accessible
- STATUS mandatory
- DESCRIPTION
- "This table contains one entry per interface."
- ::= { ifExtensions 2 }
-
- ifExtnsTestEntry OBJECT-TYPE
- SYNTAX IfExtnsTestEntry
- ACCESS not-accessible
- STATUS mandatory
- DESCRIPTION
- "An entry containing objects for invoking
- tests on an interface."
- INDEX { ifExtnsTestIfIndex }
- ::= { ifExtnsTestTable 1 }
-
- IfExtnsTestEntry ::=
- SEQUENCE {
- ifExtnsTestIfIndex
- INTEGER,
- ifExtnsTestCommunity
- OCTET STRING,
- ifExtnsTestRequestId
- INTEGER,
- ifExtnsTestType
- OBJECT IDENTIFIER,
- ifExtnsTestResult
- INTEGER,
- ifExtnsTestCode
- OBJECT IDENTIFIER
- }
-
- ifExtnsTestIfIndex OBJECT-TYPE
- SYNTAX INTEGER
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "The value of this object identifies the
- interface for which this entry contains
- information on interface tests. The value
- of this object for a particular interface
- has the same value as the ifIndex object,
- defined in [4,6], for the same interface."
- ::= { ifExtnsTestEntry 1 }
-
-
-
-
- SNMP Working Group [Page 9]
-
- RFC 1229 Interface MIB Extensions May 1991
-
-
- ifExtnsTestCommunity OBJECT-TYPE
- SYNTAX OCTET STRING
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "This object contains the name of the SNMP
- authentication community [5] which was used
- to authenticate the SNMP Message which invoked
- the current or most recent test on this
- interface. If the authentication community
- is unknown or undefined, this value contains
- the zero-length string."
- ::= { ifExtnsTestEntry 2 }
-
- ifExtnsTestRequestId OBJECT-TYPE
- SYNTAX INTEGER
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "This object contains the value of the
- request-id field in the SNMP PDU [5] which
- invoked the current or most recent test on
- this interface. If the request-id is
- unknown or undefined, this value contains
- the value zero."
- ::= { ifExtnsTestEntry 3 }
-
- ifExtnsTestType OBJECT-TYPE
- SYNTAX OBJECT IDENTIFIER
- ACCESS read-write
- STATUS mandatory
- DESCRIPTION
- "A control variable used to start and stop
- operator-initiated interface tests.
- Most OBJECT IDENTIFIER values assigned
- to tests are defined elsewhere, in associ-
- ation with specific types of interface.
- However, this document assigns a value for
- a full-duplex loopback test, and defines the
- special meanings of the subject identifier:
-
- noTest OBJECT IDENTIFIER ::= { 0 0 }
-
- When the value noTest is written to this
- object, no action is taken unless a test is
- in progress, in which case the test is
- aborted. Writing any other value to this
- object is only valid when no test is
-
-
-
- SNMP Working Group [Page 10]
-
- RFC 1229 Interface MIB Extensions May 1991
-
-
- currently in progress, in which case the
- indicated test is initiated.
- Note that noTest is a syntactically valid
- object identifier, and any conformant
- implementation of ASN.1 and BER must be able
- to generate and recognize this value.
- When read, this object always returns
- the most recent value that ifExtnsTestType
- was set to. If it has not been set since
- the last initialization of the network
- management subsystem on the agent, a value
- of noTest is returned."
- ::= { ifExtnsTestEntry 4 }
-
- wellKnownTests OBJECT IDENTIFIER ::= { ifExtensions 4 }
-
- -- full-duplex loopback test
- testFullDuplexLoopBack OBJECT IDENTIFIER ::=
- { wellKnownTests 1 }
-
- ifExtnsTestResult OBJECT-TYPE
- SYNTAX INTEGER {
- none(1), -- no test yet requested
- success(2),
- inProgress(3),
- notSupported(4),
- unAbleToRun(5), -- due to state of system
- aborted(6),
- failed(7)
- }
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "This object contains the result of the most
- recently requested test, or the value
- none(1) if no tests have been requested since
- the last reset. Note that this facility
- provides no provision for saving the results
- of one test when starting another, as could
- be required if used by multiple managers
- concurrently."
- ::= { ifExtnsTestEntry 5 }
-
- ifExtnsTestCode OBJECT-TYPE
- SYNTAX OBJECT IDENTIFIER
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
-
-
-
- SNMP Working Group [Page 11]
-
- RFC 1229 Interface MIB Extensions May 1991
-
-
- "This object contains a code which contains
- more specific information on the test result,
- for example an error-code after a failed
- test. Error codes and other values this
- object may take are specific to the type of
- interface and/or test. However, one subject
- identifier:
-
- testCodeUnknown OBJECT IDENTIFIER ::= { 0 0 }
-
- for use if no additional result code is
- available.
- Note that testCodeUnknown is a
- syntactically valid object identifier, and
- any conformant implementation of ASN.1 and
- the BER must be able to generate and
- recognize this value."
- ::= { ifExtnsTestEntry 6 }
-
-
- -- Generic Receive Address Table
- --
- -- This group of objects is mandatory for all types of
- -- interfaces which can receive packets/frames addressed to
- -- more than one address.
-
- ifExtnsRcvAddrTable OBJECT-TYPE
- SYNTAX SEQUENCE OF IfExtnsRcvAddrEntry
- ACCESS not-accessible
- STATUS mandatory
- DESCRIPTION
- "This table contains an entry for each
- address (broadcast, multicast, or uni-cast)
- for which the system will receive packets/
- frames on a particular interface. When an
- interface is operating in promiscuous mode,
- entries are only required for those addresses
- for which the system would receive frames
- were it not operating in promiscuous mode."
- ::= { ifExtensions 3 }
-
- ifExtnsRcvAddrEntry OBJECT-TYPE
- SYNTAX IfExtnsRcvAddrEntry
- ACCESS not-accessible
- STATUS mandatory
- DESCRIPTION
- "A list of objects identifying an address
- for which the system will accept packets/
-
-
-
- SNMP Working Group [Page 12]
-
- RFC 1229 Interface MIB Extensions May 1991
-
-
- frames on a particular interface."
- INDEX { ifExtnsRcvAddrIfIndex, ifExtnsRcvAddress }
- ::= { ifExtnsRcvAddrTable 1 }
-
- IfExtnsRcvAddrEntry ::=
- SEQUENCE {
- ifExtnsRcvAddrIfIndex
- INTEGER,
- ifExtnsRcvAddress
- PhysAddress,
- ifExtnsRcvAddrStatus
- INTEGER
- }
-
- ifExtnsRcvAddrIfIndex OBJECT-TYPE
- SYNTAX INTEGER
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "The value of ifIndex, defined in [4,6], of an
- interface which recognizes this entry's
- address."
- ::= { ifExtnsRcvAddrEntry 1 }
-
- ifExtnsRcvAddress OBJECT-TYPE
- SYNTAX PhysAddress
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "An address for which the system will accept
- packets/frames on this entry's interface."
- ::= { ifExtnsRcvAddrEntry 2 }
-
- ifExtnsRcvAddrStatus OBJECT-TYPE
- SYNTAX INTEGER {
- other(1),
- invalid(2),
- volatile(3),
- nonVolatile(4)
- }
- ACCESS read-write
- STATUS mandatory
- DESCRIPTION
- "This object has the value nonVolatile(4)
- for those entries in the table which are
- valid and will not be deleted by the next
- restart of the managed system. Entries
- having the value volatile(3) are valid
-
-
-
- SNMP Working Group [Page 13]
-
- RFC 1229 Interface MIB Extensions May 1991
-
-
- and exist, but have not been saved, so
- that will not exist after the next
- restart of the managed system. Entries
- having the value other(1) are valid and
- exist but are not classified as to whether
- they will continue to exist after the next
- restart. Entries having the value invalid(2)
- are invalid and do not represent an address
- for which an interface accepts frames.
- Setting an object instance to one of
- the values other(1), volatile(3), or
- nonVolatile(4) causes the corresponding
- entry to exist or continue to exist, and
- to take on the respective status as regards
- the next restart of the managed system.
- Setting an object instance to the value
- invalid(2) causes the corresponding entry
- to become invalid or cease to exist.
- It is an implementation-specific matter
- as to whether the agent removes an
- invalidated entry from the table.
- Accordingly, management stations must be
- prepared to receive tabular information
- from agents that corresponds to entries not
- currently in use. Proper interpretation of
- such entries requires examination of the
- relevant ifExtnsRcvAddrStatus object
- instance."
- DEFVAL { volatile }
- ::= { ifExtnsRcvAddrEntry 3 }
-
- END
-
- 6. Acknowledgements
-
- Most of the MIB objects defined in this document were originally
- proposed as a part of a MIB for management of IEEE 802.5 Token Ring
- networks, as prepared by:
-
- Eric B. Decker, cisco Systems, Inc., and
- Richard Fox, Synoptics Inc.
-
- In addition, the comments of the following individuals are
- acknowledged:
-
- James R. Davin, MIT-LCS
- Stan Froyd, ACC
- Frank Kastenholz, Racal Interlan
-
-
-
- SNMP Working Group [Page 14]
-
- RFC 1229 Interface MIB Extensions May 1991
-
-
- Dave Perkins, 3Com
- Marshall T. Rose, PSI
- Bob Stewart, Xyplex
- David Waitzman, BBN
- Wengyik Yeong, PSI
-
- 7. References
-
- [1] Cerf, V., "IAB Recommendations for the Development of Internet
- Network Management Standards", RFC 1052, NRI, April 1988.
-
- [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review
- Group", RFC 1109, NRI, August 1989.
-
- [3] Rose M., and K. McCloghrie, "Structure and Identification of
- Management Information for TCP/IP-based internets", RFC 1155,
- Performance Systems International, Hughes LAN Systems, May 1990.
-
- [4] McCloghrie K., and M. Rose, "Management Information Base for
- Network Management of TCP/IP-based internets", RFC 1156, Hughes
- LAN Systems, Performance Systems International, May 1990.
-
- [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
- Network Management Protocol", RFC 1157, SNMP Research,
- Performance Systems International, Performance Systems
- International, MIT Laboratory for Computer Science, May 1990.
-
- [6] Rose M., Editor, "Management Information Base for Network
- Management of TCP/IP-based internets: MIB-II", RFC 1213,
- Performance Systems International, March 1991.
-
- [7] Information processing systems - Open Systems Interconnection -
- Specification of Abstract Syntax Notation One (ASN.1),
- International Organization for Standardization, International
- Standard 8824, December 1987.
-
- [8] Information processing systems - Open Systems Interconnection -
- Specification of Basic Encoding Rules for Abstract Notation One
- (ASN.1), International Organization for Standardization,
- International Standard 8825, December 1987.
-
- [9] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
- RFC 1212, Performance Systems International, Hughes LAN Systems,
- March 1991.
-
- 8. Security Considerations
-
- Security issues are not discussed in this memo.
-
-
-
- SNMP Working Group [Page 15]
-
- RFC 1229 Interface MIB Extensions May 1991
-
-
- 9. Author's Address
-
- Keith McCloghrie
- Hughes LAN Systems, Inc.
- 1225 Charleston Road
- Mountain View, CA 94043
-
- Phone: (415) 966-7934
-
- EMail: kzm@hls.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- SNMP Working Group [Page 16]
-